MODULES-11721: Add Puppet 9 support - #475

Summary

Adds Puppet 9 support to puppetlabs-java_ks. Widening the version bound in metadata.json is a one-line change; the rest is the dependency and workflow work needed to make the Puppet 9 lane actually run. Same approach as puppetlabs/puppetlabs-firewall#1302.

No behaviour changes — no .pp, type, provider or spec file is touched.

metadata.json

• puppet requirement: >= 8.0.0 < 9.0.0 → >= 8.0.0 < 10.0.0.
• dependencies is empty, so nothing else needed widening.
• operatingsystem_support deliberately unchanged — EOL platforms are dropped from the Puppet 9 lane only (see below), preserving their Puppet 8 coverage.

Gemfile

This module went through two rounds of revision after the PR was first opened, both driven by comparing against sibling modules in the same epic once they landed:

1. puppetlabs_spec_helper and puppet_litmus were originally pinned to unreleased git main branches, since neither released version had the features above yet. Both shipped as real releases shortly after, so the pins were swapped for the released versions. This also required updating Rakefile's require 'puppet-syntax/tasks/puppet-syntax' to require 'puppetlabs-syntax/tasks/puppetlabs-syntax', since puppetlabs_spec_helper 9.0.0 renamed that dependency.
2. Puppet 9 gem resolution originally went through a hand-rolled PUPPET_GEM_SOURCE-based branch, needed because at the time only an internal/Twingate source carried a Puppet 9 prerelease build. Comparing against puppetlabs-windows_eventlog#100 (MODULES-11729) showed that puppet 9.0.0 is now a real, final release on the standard puppetcore source — confirmed by CI here resolving puppet (9.0.0) directly, so that branch was simplified to a plain source lookup. An Opus review of that simplification caught that this module's location_for helper is a 2-argument variant that can't accept/merge a source: option — using it with a third argument here would have raised a hard Bundler error on every Puppet 9 CI job. Fixed by using the literal array form instead, matching the style of the pre-existing PUPPET_FORGE_TOKEN branch immediately below it.

This ordering is still load-bearing, not cosmetic. The pre-existing elsif !ENV['PUPPET_FORGE_TOKEN'].to_s.empty? branch hardcodes puppet ~> 8.11, ignoring PUPPET_GEM_VERSION. CI sets both that token and PUPPET_GEM_VERSION=~> 9.0, so had the Puppet 9 check been placed after it, the Puppet 9 spec leg would have silently resolved Puppet 8.11 and reported green while never testing Puppet 9 at all.

.github/workflows/ci.yml, nightly.yml, mend.yml

• ruby_version: "3.2". Each job runs bundle lock over the :development group at the reusable workflow's default ruby (3.1), which can no longer resolve voxpupuli-puppet-lint-plugins 7.0 (requires ruby >= 3.2).
• secrets: inherit was already present on this module's Spec job, so unlike firewall#1302 nothing needed adding there.
• Seven --collection-platform-exclude flags on Acceptance (see below).

.sync.yml

• ci.yml and nightly.yml marked unmanaged: true — they carry ruby_version/additional_packages inputs pdk-templates can't express. (--collection-platform-exclude itself is expressible via the template's acceptance_flags key — corrected a comment that previously implied otherwise.)
• New overrides: entries under the existing Gemfile: key (which already carried a ruby-pwsh optional-gem entry) pinning puppetlabs_spec_helper (~> 9.0) and puppet_litmus (~> 2.8) above pdk-templates' own looser defaults, so a scheduled pdk update can't silently revert either.

Additional Context

Which platforms are excluded from the Puppet 9 lane, and why

9:redhat-7, 9:centos-7, 9:oraclelinux-7, 9:scientific-7, 9:debian-10, 9:ubuntu-18.04, 9:ubuntu-20.04

Seven entries rather than firewall's four, because firewall already drops the el-7 clones outright via unconditional --platform-exclude, whereas this module genuinely tests CentOS 7 / OracleLinux 7 / Scientific 7 under Puppet 8. Every exclude is scoped to collection 9, so Puppet 8 coverage is untouched.

Cross-checked against puppet-agent-private/configs/platforms/ on the 9.x line, which no longer contains el-7-*, debian-10-*, ubuntu-18.04-* or ubuntu-20.04-*. SLES 12 is still built for Puppet 9, so 9:sles-12 is deliberately not excluded.

No excludes were added for AIX 7.1, Solaris 11, or any Windows release: none of them appear in the generated matrix on any Puppet major, because litmus has no docker or provision_service image configured for them. That is a pre-existing coverage gap unrelated to Puppet 9, and inventing excludes for untested platforms would be misleading.

Verification

Locally on ruby 3.2.9: rake syntax, rake lint, rake metadata_lint all clean; rake parallel_spec 62 examples, 0 failures. manifests/config.pp (the module's only manifest) already satisfies puppet-lint 5.x's strict_indent, so no whitespace edits were needed.

provision.yaml was left untouched — it looks stale (debian-8, ubuntu-1404) and is unused by GitHub Actions CI, which drives entirely off matrix_from_metadata_v3.

In CI: the Puppet 9 Spec lane resolves and installs the real puppet (9.0.0) release from puppetcore and passes.

Related Issues (if any)

• MODULES-11721
• Pattern reference: MODULES-11717: Add Puppet 9 support puppetlabs-firewall#1302 (MODULES-11717), (MODULES-11729) Add Puppet 9 support puppetlabs-windows_eventlog#100 (MODULES-11729)
• Epic: MODULES-11698

Checklist

• 🟢 Spec tests. — 62 examples, 0 failures locally; the Puppet 9 leg also passes in CI against the real released puppet 9.0.0.
• 🟢 Acceptance tests. — covered by this PR's CI matrix; not runnable locally.
• Manually verified. — n/a, no behavioural change.

🤖 Generated with Claude Code